In general, access control mechanisms based on labels do not address the requirements from application domains where the label structure and the label access rules do not necessarily match those specific to Multilevel Security (MLS).
Access control regulates the reading, changing, and deleting of objects stored on a computer system. Access control further prevents the accidental or malicious disclosure, modification, or destruction of such objects. Fundamental types of access control comprise discretionary access control (DAC), role-based access control (RBAC), and mandatory access control (MAC). DAC permits the granting and revoking of access privileges to be left to the discretion of the individual users. RBAC does not allow users to have discretionary access to objects. Instead, access permissions are associated with roles; users are made members of appropriate roles. MAC, as defined in the Trusted Computer Security Evaluation Criteria (TCSEC) is “a means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity”
One implementation of MAC is Multilevel Security (MLS) that has typically been available primarily on computer and software systems deployed at sensitive government organizations such as the intelligence services or the military.
An MLS model is stated in terms of objects and subjects. An object is a passive entity such as a data file, a record, or a field within a record. A subject is an active process that can request access to objects. The object is assigned a classification, and the subject is assigned a clearance. Classifications and clearances are collectively referred to as access classes or labels. A label is a piece of information that comprises a hierarchical component and a set of unordered compartments.
The hierarchical component specifies the sensitivity of the data. For example, a military organization might define levels top secret, secret, confidential, and unclassified. The compartments component is non-hierarchical and is used to identify areas that describe the sensitivity or category of the labeled data. For example, a military organization might define compartments NATO, nuclear, and army. Labels are partially ordered in a lattice as follows: given two labels L1 and L2, L1>=L2 if and only if the hierarchical component of L1 is greater than or equal to that of L2, and the compartment component of L1 includes the compartment component of L2. L1 is said to “dominate” L2.
MLS restricts data accesses through a simple security property and a *-property (pronounce “the star property”). The simple security property allows a subject read access to an object if and only if the subject's label dominates the object's label. The *-property allows a subject write access to an object if and only if the object's label dominates the subject's label. The *-property prevents subjects from declassifying information.
Even though MLS has traditionally been a requirement of some sensitive government organizations, such as the intelligence services or the military, the ever-increasing customer demand for higher security has made MLS attractive for commercial software products. For example, in certain implementations, the DBMS controls access to database table rows based on a label contained in the row and the label associated with the database user attempting the access. The drawbacks of such implementations comprise a fixed label structure and fixed access rules.
MLS fixes the label structure of a hierarchal component and a set of unordered compartments. Thus, the labels cannot be used for other types of applications to provide fine-grained access control to database table rows. For example, in certain banking applications, a label represents a geographical location, which is a single component and is not hierarchal. MLS further fixes access rules. Access to database table rows is governed by the simple security property and the *-property. Thus, this form of access control based on labels cannot be used for other purposes. For example, banking applications have different requirements for the label structure and for the label access rules.
Although this technology has proven to be useful, it would be desirable to present additional improvements. Existing access control systems based on labels strictly implement the MLS semantics. These conventional access control systems fail to address the label requirements from application domains where the label structure and the label access rules do not necessarily match those described in MLS. Moreover, these existing solutions cannot be used to enforce privacy policies. Generally, a privacy policy indicates for which purposes an information is collected, whether or not the collected information will be communicated to others, and for how long the collected information is retained before it is discarded.
For example, a user should not be able to access a customer record for the purpose of sending that customer marketing information if that customer did not agree to receipt of such information. Access to privacy-sensitive data can be regarded as analogous to access to labeled data. In both cases, a tag is associated with the object being accessed and the subject accessing that object. The tag is a “purpose” in the case of the accessing privacy-sensitive data and a “label” in the case of the accessing labeled data.
However, existing access control solutions based on labels strictly implement the MLS semantics, and thus cannot be used to enforce privacy policies for the following reasons. Labels include a hierarchal component that is not applicable in the case of privacy. Furthermore, the MLS security properties do not apply in the context of privacy.
What is therefore needed is a system, a computer program product, and an associated method for a label-based access control (LBAC) solution that is capable of implementing the MLS semantics and of addressing the requirements from a variety of application domains, including MLS requirements. The need for such a solution has heretofore remained unsatisfied.